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(54) Abstract Title 

A shadow function blocic interffaoe for use in 8 



(57) A process controller that is communicatively 
coupled to an external fieid device via a communication 
network uses a shadow function kilocic 108 disposed 
within a process controller 12 to enable implementation of 
a control routine that uses kxith an Internal function blocic 
152 disposed within the process controller 12 and an 
external function blocic 112 disposed within the extemal 
field device 4a The shadow function blocic 108 includes a 
communication port that communicates with the extemal 
function blocic 112 via the communication network (and 
possibly an interface card 40) to thereby receive data 
pertaining to the extemal function blockr 8 memory 156 
that stores the received data according to a configuration 
protocol of the internal function block 152 and an output 
that provides the stored extemal function block data to the 
intemal function block according to the configuration 
protocol of the intemal function block. The 
ccmimunication port of the interface function block may 
include an output that sends data generated liy the 
controller or the intemal function block to the extemal 
function block using the communication protocol (e^. 
Fietdbus) associated with the octemal function block. 
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The references to Rgure 13 of the drawings in the printed specification ara to be treated as omitted under Sectk)n 
15(2) or (3) of the Patents Act 1977. 
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A SHADOW FUNCTION BLOCK INTERFACE FOR 
USE IN A PROCESS CONTROL NETWORK 

PTp n HP THF INVENTION 
The present invention relates generaUy to process control networks and, 
more specifically, to a process controller that uses shadow function blocks to 
represem inforination associated with extenial fimction blocks distrita 

throughout a process conttol network. 

pyOTlPnON PC TCTP PKI ATED ART 
Process control networks, such as those used m chemical, petroleum or 
other processes, generally include a centralized process controller communicatively 
coupled to one or more field devices which may be. for exan^le. valve positioners, 
switches, sensors (such as temperamre, pressure and flow rate sensors), etc. These 
field devices may perform control functions within the process (such as opening or 
ctosmg a valve), may take mc?asurements within Ae process for use in controUing 
the operation of the process or may perform any other desired function within the 
process. Piocess controUers have historically been connected to field devices via 
one or more analog signal lines or buses which may cany, for example. 4-20 mA 
(milliamp) signals to and from die field dcvfces. Generally speaking, the process 
controller receives signals indicative of measurements made by one or more field 
devices and/or other mformation pertaining to one or more field devices, uses this 
information to implement a typically complex control routine and then generates 
control signals which are sent via the analog signal buses to one or more of the field 

devices to tiiereby owtrol the operation of die process. 

Recently, there has been a naovc widun the process control industry to 

«»pi«.«M>nt field-based digital commmiirartrois within the process control 
environmem. Ftor example, the process control industry has developed a number of 
standard, open, digital or combined digital and analog communication protocols 
such as die HARr, PROFIBUS*. WORLDFIP*. Device-Net* and CAN protocols. 
These digital communication protocols generally enable more field devices to be 
connected to a particular bus, si^^rt more and fester communication between the 
field devices and the controller and/or allow fieki devices to send more and 
differem types of mformation. such as infoimation pertaining to die stadis and 



configuration of the field device itself, to the process controUer. Furthermore, 
these standard digital protocols enable field devices made by different manufecmrers 
to be used together within the same process control network 

Also, there is now a move within the process control industry to decentralize 
process conttol and, thereby, simplify process controllers. Decemralized coiitiol is 
obtained by having field mounted process control devices, such as valve positioners, 
ttansmitters, etc. perform one or more process control functions using what are 
typically referred to as faa^on blocks and by then communicating data across a bus 
strucmre for use by other process control devices (or function blocks) in performing 
other control functions. To in5)lement these control functions, each process control 
device typically includes a micropiocessor having the capability to implement one 
or more function blocks as weU as the ability to communicate with otfwr process 
control devices using a standard and open communication protocol. In this mamicr. 

field devices can be interconnected within a process control netwoik to 
communicate with one another and to perform one or more process control 
functions forming a control loop without the intervention of a centralized process 
controUer. The all-digital, two-wire bus protocol now being promulgated by the 
Fieldbus Foundation, known as the Foundation™ Fieldbus (hereinafter 
•Fieldbus") protocol is one open communication protocol that aUows devices made 
by different manufecturers to interopeiate and communicate with one anotto 

standard bus to effect decentralized control wiflrin a process. 

Because digital communication protocols and decentralized control schemes 
(such as that used in the Fieldbus control environment) are so new. processes which 
implement these protocols typically do so only to a limited extent. Asaresult, 
newer process coniroUers . such as the DeltaV™ process controUer manufectored by 
Fisher-Rosemont Systems support both analog and digital communication protocols 
and hardware and can be programmed to hnplcment control in a process that 

inchides field devices which communicate using standard analog protocols, such as 
the 4-20 mA protocol , and one or more of the newer digital protocols, sudi as the 
Fieldbus protocol. 



However, problems have arisen when trying to integrate control of analog 
and digital field devices, and particularly Fieldbus field devices, in a process 
control network using a centralized controller. Because the control functions for 
amlog field devices and some digital field devices are nxqilemented within the 
S centralized process controllo-, all the necessary information about diese field 

devices is received by and stt>red within die centralized process controller. This in 
turn enables the centralized proc^ controller to integrate control of the different 
analog and digital field devices, to display the current configuration and state of the 
prations of the process control network in which these devices are located, to make 

10 dianges to the process control network configuration with respect to these devices. 

However, when a decentralized control scheme, sudi as Oie Fieldbus control 
scheme, is used in a part of the process, the centralized process controller no longer 
needs or has direct access to all of d» current information being used by or 
associated with the process control devices subject to the decentralized TO In 

15 fact, some dec^itralized process control protocols, such as ttie Fieldbus protocol, 
are specifically designed so that it is not necessary to send information to a 
centralized process controller on a regular basis. This fact makes it difficult for the 
centralized process controller to integrate the control of the analog or other digital 
field devices with the field devices subject to decentralized control. Also, it makes 

20 it difficult for Oie centralized process controller to model or display the current state 
of the devices subject to decentralized control or within a decentralized portion of 
the process control network. 

In £act, for the centralized process controller to receive information from ttie 
decentralized control portion of the process control network, the field devices (or 

25 function blocks) within that portion of the process must be specifically configured to 
send information directly to die centralized process controller (which means that the 
centralized process controller must receive and track all of this information, most of 
which is not necessary for operation of tiie centralized process controller). 
Alternatively, the centralized process controller must actively request to receive the 

30 information it needs. Because such a request is not given a high prioriQf in, for 
exanq>le, the Fieldbus protocol, by the time the centralized process controller 



receives the requested information, this infonnation may be out of date. 
Furthennore. it is difBcult. if not impossfcle for the centralized process controller 
to request and receive data that is active or current at a specified time. Instead, the 
centralized process controUer only receives the data active at the time the re^ 
reaches the field device. StiD further, communication between the centralized 
process controller and field devices within the decentralized portion of the process 
is highly specialized and requires considerable knowledge of the decentralized 
control protocol, which makes it difBcult for the designer of the centralized process 
control routine Wimpiement this communication on an as needed basis. 

ff ^y^yivf AWY OF T HF TNVFNTION 
The presem iiivention is directed to the use of shadow function blocks to 

integrate, in a centralized process controUer, the control of function blocks residmg 
in the centralized controUer with those residhig in an external device, such as a 
device The present invention may also be used to enable a controller to control 
and communicate with devices or function blocks that arc located in a 
communication network or that use a communication protocol that is different than 
that used by the controller. In particular, a shadow function block is set up in the 
centralized controUer to mirror the data associated with an external function block 
located in an external device , such as in a field device conforming to a decentralized 
control and communication protocol. The control routine of the centralized 
controller communicates with the external function block via the shadow function 
block as if the external function blodc was being inq>lemenied by the central^ 

controUer. The shadow function block automaticaUy obtains current information 
associated with the external function blo<* and sends commands to the external 

function block using the protocol associated with the external (e.g., decentralized) 
control protocol. In the case of a Fieldbus protocol, this communication is 
accomplished using both synchronous and asynchronous communications. 
However, the shadow fimction blodc communicates with other fimction blocks 
withm the centraUzed controUer as if the external fimction block is being fiiUy 

implonented by the centralized controUer, 



Using the shadow funcdon block of the present invention, the centralized 
process control routine can receive up-to-date information about the actual function 
block on a real-time or near real-time basis because this information is mirrored in 
the shadow function block which is always accessible to the centra 
5 control routine. Likewise, the centralized process control routine can send 
r^fiifiiaiMig to the actual function block by sending a command to the shadow 
function block without regard to the type or location of the device in whi 
actual function block is located. The shadow function block dien immediately 
relays this command to the actual function block using die appropriate 

10 communication commands associated wifli tiie decentralized process control 

protocol. In this nianner, the centralized process control routine does not need to 
perform aiiy significant database control with reqpect to all of the field devices 
within the decentralized control portion of tibe process because die information it 
needs for field devices within the decentralized portion of the process control 

IS network is located in the shadow function block(s). Likewise, the centralized 

process control routine does not need to be specifically programmed to deal with the 
complex and demanding tasks of communicating in the decentralized process control 
protocol because this communication is performed automatically by the shadow 
function block. 

20 According to one aspect of the present invention, an interface or shadow 

function block is adapted to be used in a process controller communicatively 
coupled to an external device via a communication network to enable the process 
controller to inq>lement a control routine using both an internal function block 
residii^ in the process controller and an external function blodc residing within the 

25 external device. The interface or shadow fimction blodc according to this aspect of 
the invention includes a communication port having an input that communicates 
with the external function block via the communication network to thereby receive 
data pertaining to the external function block Bnd a rr^mory that stores the received 
data pertainiiig to the external function block according to a configuration protocol 

30 of the internal function blodc. If desired,, tfie interface fimction block may also 

include an ouQmt that provides the stored external function block data to the internal 



function block using the configuration protocol of the internal function block. 
Likewise, the communication port of the interface function block may include an 
ou^t that sends data (such as linked data or commands) to the external function 
block using a communication protocol associated with the external function block. 
S Preferably, the ccmununication port of die interface function block receives 

the data pertaining to die external function blodc independently of the operation of 
the internal function blocks. Likewise, in om embodiment, the external function 
block communicates via ttie communication network using a first conmiunication 
protocol that is different than a second communication protocol associated with the 

10 internal function block and, in this case, the communication port co m munica t es with 
the extenial function blodc using the first commumcation protocol and the ouqput of 
die incerfoce function block communicates widi the internal function block 
accordii^ to the second communication protocol. 

If desired, the first communication protocol associated with the external 

IS function block may be the Fieldbus communication protocol. In this case, the 
communication port may use an interface device (such as an interfiace card) 
configured to communicate with the external device using the Fieldbus 
communication protocol to thereby communicate widi the external function block. 
The commumcation port may, for exan^ile, communicate with the external function 

20 block using S3mchroiious communications, such as die publisher/subscriber 

relationships of the Fieldbus communication protocol, and/or using asyndironous 
commumcations, such as die view objects of the Fieldbus communication protocol. 
More gen^^y, the external device may communicate using a device 
communication protocol that supports die communication of logically linked pactets 

25 of data using standardized communication calls, sudi as the view objects and view 
alerts of the Fieldbus communication protocol, and the communication port may 
communicate with the external function block using the standardized communication 
calls. Likewise, the communication port may receive alarm indications from the 
external function block and store these alarm indications in memory for use by the 

30 controller. 
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According to another aspect of the present invention, a controller adapted to 
be communicatively coupled to a plurality of field devices iKludes a processor, a 
memoiy and a control routine stored in the memory and inq>lemeiited by the 
processor to control the plurality of field devices. The control routine includes a 
multiplicity of interconnected internal fimcdon blocks configured using a controller 
protocol to be inq)lemented by ibt controller and an interface function block diat 
communicates widi one of the interconnected internal function blocks using the 
controller protocol and that communicates with an external function block residing 
in an external field device using a field device communication protocol. The 
interface function block stores data pertainiqg to the external funcdon blodc 
received fincmi the external funcdon block for use by die control routine. 

According to a further aspect of die present invradon, a method of 
inq>lemmtii% a control routine widiin a process controller stores, widiin the 
controller, a plurality of interconnected intmal function blocks configured 
according to a controller protocol for insplementation as part of the control routine. 
The method also creates, within the controller, an interfiice function block that is 
configured according to the controller protocol but which communicates with an 
external function block located in an external field device using a device 
communication protocol associated with the external device. The method then 
creates a control routine that uses the plurality of interconnected internal function 
blodcs and the interface function block to control the process and, durii^ 
inqplementation of the control routine, stores data associated with and received from 
the externa function block in die interfile function block fior use by d» control 
routine as if the otenial function block were being implemented by the controller 
as one of the internal function blocks. 

The method may allow a user tt> configure the control routine by specifyii^ 
each of a number of function blocks to be used in the control routine, identifying 
die interconnections between the specified function blocks to be used in die control 
routine and specifyii^ the location of a particular specified function block as being 
an internal function block in^lemcaiied in the controller or an external function 
block implemented by a field dcvke. In die case in which a function block is to be 



implemenied in an external device, the method includes the step of selecting an 
external device from a list or set of devices connected within the system. 

TOTPF nRCTlPTfAM OF THF DRAWINGS 

Fig. 1 is a sch«^*ic blodc diagram of an cxBsaplc process control network 
having centzalized and decentralized process control portions therein: 

Fig. 2 is a schematic block diagram of three standard function blocks 
associated with one or more Fieldbus field devices; 

Fig. 3 is a timing schematic for a macrocycle of a segment of a Fieldbus bus 
located widiin the process control network of Fig. 1 ; 

Fig. 4 is a schematic block diagram depicting the interconnection of a 
shadow fimction block with other blocks associated with a centralized process 
control routine located widiin a cmiralized process controller; 

Fig. 5 is a block diagram of part of a process control system using the 
shadow function block of Ae present inventicm; 

Fig. 6 is a flow djan iUustrating the installation of a control module widun 

the controller of Fig. 1; 

Fig. 7 is a flow chart illustrating the installation of a link acdve schedule in 
the Fieldbus portion of the process control network of Fig. 1; 

Fig. 8 is a flow chan illustrating the installation of publisher links in the 
Fieldbus portion of the process control network of Fig. 1; 

Fig. 9 is a flow chart iUustratiiig die installation of a device configuration in 
a device within die Fieldbus portion of die process control network of Fig. 1; 

Fig. 10 is a flow chart iUustrating the installation of a function block widiin 
a device in the Fieldbus portion of die process ccmtrol network of Fig. 1; 

Fig. 11 is flow chart illustrating the operation of the shadow function block 
and related conqwnents during operation of a centralized control module using the 
shadow function block; and 

Fig. 12 is a flow chart illustrating die communication of data and write 
requests ftom a block in a centralized controller or a user to an external function 
blodc in a field device using the shadow fimction block of the present invention. 



DESCRIPTION OF THE PREFERRFD FMBODIMENTS 
Referring now to Fig. I, a process control networic 10 is illustrated in block 
diagram form. The process control network 10 includes a centralized process 
controller 12 capable of inqilementiiig a i»ooess control routine stored therein. The 
controller 12 may be, by way of example only» the DeltaV™ controller sold by 
Fisher-Rosemom Systems and may be connected to numerous workstations such as 
personal conqniters (PCs) 14 via a hub 16 and ethemet ccmnections 18. In this 
configuration, die PCs 14 may be used by one or more operators or users to 
communicate with the process controller 12 to thereby obtain information pertaining 
to the process control networic 10, to review or change the status of the process 
control network 10, to obtain information pertaining to individual field devices 
within the process control network.lO, etc. If die controller 12 is a DeltaV 
controller, it may provide a gnqducal dq^iction of the process ccmtrol routine within 
the controller 12 to die user via one of die PCs 14 illustrating the function blocks or 
control blocks within the process control routine and the manner in which these 
function blocks are linked tog^her to provide control of a process. The user may 
be able to alter the process control routine within the centralized process controller 
12 by manipulatiqg the gn^hical dqiiction of the function blocks within the control 
routine to add or delete fimcdon blocks from that control routine and/or to change 
the way in which the fuixrdon blocks associated with the control routine are linked, 
i.e., die way in which they are intnoonnBCted. 

As illustrated in Fig. 1, the cenfraliTird controller 12 is connected to 
numoous field devices located throughout a process (indicated gcKrally by 
reference nuniber 19). The centralized controller 12 may comnninicate through any 
standard types of I/O cards 20 and 22 io field devices 26, 28, 30, 32, 34 and 36 
which are subject to centralized control firom tte controller 12. The I/O card 20 
may be, for examples, an analog I/O card that connects the controller 12 to analog 
field devices 24 aiKl 26 which communicate over 4 to 20 mA buses 38. Likewise, 
the I/O card 22 may be a digital or combined digital and analog I/O card that 
communicates with digital or mixed digital and analog fiekl devices in any desired 
format including, for exanq>le, the 4 to 20 mA analog format or any known or 



standard digital foimat. Of course, the field devices 26, 28, 30, 32, 34 and 36 may 
be any desired types of field devices indudii^ transmitters, sensors, valve 
positioners, valve conficoUcrs. etc. As wiU be understood for the example process 
control network 10 illustrated in Fig. 1, the fidd devices 26-36 are associated with 
portions of the process 19 sutject to centralized control by the control routine 

within the controUo' 12. 

The controller 12 is also communicatively connected to an interface card 40 
which, in turn, is connected to (or is part of) an external process control network in 
which process control is performed in a distributed manner or which has devices 
having function blodcs dutt ccnmnumcate usintg a communication protocol that is 
differcntthanthatusedwiflun the controller 12. In the embodiment illustrated in 
Fig. 1, the decentralized i«ocess c(»itrol potticm of flie process 19 includes the 
inter&ce card 40, a bus 42 and oomaons field devices 43, 44, 46, 48 and 50 
connected to the bus 42. The distributed process amtrol network of Fig. 1 may be, 
for example, a Fieldbus network whidi uses tihe Fieldbus communication protocol. 
As will be discussed in more detail herein, the interface card 40 may be a link 
active scteduler associated with the Fieldbus communication protocol. 

The centralized process control routine located within the controller 12 
receives ii^nits from the fiekl devices 26-36 and potentiaUy 43-50, performs 
calculations and other activities associated with the control routine and then sends 
commands to the field devkes via the I/O cards 20 and 22 and the interface card 40 
to hnplemem any desired control of the process 19. It should be noted, however, 
that the decentralized process ccmtrol portion of the process control networic 10 
(i.e., that associated with the bus 42 in Fig. 1) may inqilenient its own process 
control routine in a decentralized manner, as will be described herein, in 
conjunction with the control being perfonned by the controller 12. Thus, while the 
controller 12 may interface with and perform some control over the devices 43-50 
connected to the bus 42. these devices may also implement control functions or 
function blocks that are associated with control implemented by the controller 12 
but that are, instead, distributed throughout die devices connected to the bus 42. 
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WhUe, in the preferred embodiment, the decentralized portion of the process 
control network 10 uses the Fieldbus communication and control protocol, it could 
use any other known or desired protocol as well, including protocols developed in 
the fumre. Furthemiore, the shadow function block disclosed herein may be used 
to enable commumcation between zay two difSerent control or communication 
protocols and is not limited to use between a centralized control routine and a 
decentralized control network such as one use the Fieldbus protocol. It could, for 
exan^)le, be used between two different centralized control routines or protocols 
having control blocks therein. In other words, tfie shadow function block described 
herein is not limited to use with function blocks in the Fieldbus protocol or even to 
a protocol associated with a derrntralized control routine, but can be used to enable 
a controller (or other device) to commonicaie with any other external device tbzt 
uses any different type of communication protocol. 

Before discussing the details of the shadow function block of the present 
invention and the manner in whicAtite centralized process control!^ 12 uses such a 
shadow function block to implement control in a process control network, a general 
description of the Fieldbus protocol, field devices configured accordir^ to this 
protocol, and the way in whidi communication occurs in the section of the process 
control network 10 that uses the Fieldbus protocol wiU be provided. It shoiild be 
understood that, while the Fieldbus protocol is a relatively new all-digital 
communication protocol developed for use in process control networks, this 
protocol is known in the art and is described in detail in numerous articles, 
brtiduues and ^leciflcations published, distributed, and available from, amoiig 
others, the Fieldbus Foundation, a not-for-profit organization headquartmd in 
Austin, Texas. In particular, die Reldbus protocol, and die manner of 
communicating widi and storing data in devices using die Fiieldbus protocol, is 
described in detail in the manuals entided Corrmmnications Technical Specification 
and User Layer Technical Specification fmn d^ Heldbus Foundation. 

Generally speakit^, the Fieldbus protocol is an all-digital, serial, two-way 
comnnmication protocol that provides a sfandarrfTi*^ physical interface to a two- 
wire loop or bus intercormectiqg "field* equqiment such as sensors, actuators, 
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controllers, valves, etc. located in an instrumentation or process control 
environment of. for exanple. a fectory or a plant. The Fieldbus protocol provides, 
in effect, a local area network for field instruments (field devices) within a process, 
which enables these field devices to perform control fimctions at locations 
distributed fliroughout a process fiualiiy and to communicate with one anothCT 
before and after the performance of these control functions to implemem an overaU 

control strategy. Because the Fieldbus protocol enables control functions to be 
distributed throughout a process control network, it reduces the workload of the 
centralized process controller for those field devices or areas of the process. 

A process control network usiflg the Fieldbus protocol may include a host 
connected to a number of other devices such as a program logic coniroUers . other 
host devices and field devices via a two-we FieWbus loop or bus. such as the bus 

42 of Fig. 1. The Fieldbus bus may inctode different sections or segments 
separated by bridge devices, wherein each section of the bus interconnects a subset 
of the devices attached to the bus to «iable communications between the devices in 
a manner described hereinafter. TypicaUy. a configurer is located in one of flie 
devices, such as a host, and is responsible for setting up or configuring each of the 
devices (which are "smart" devices in that they each include a microprocessor 
capable of performing communication and. in some cases, control functions) as well 
as recogi^ when new field devices ate connected to the Fieldbus bus. when field 

devices are reinoved from the bus. recognizing data generated by the field devices 
connected to the bus. and interfewmig with one or more user terminals, which may 
be located in flie host or in any other device connected to the host in any manner. 

Hie FieWbus bus supports or allows two-way . purely digital communication 
and may also provide a power signal to any or all of the devices connected thereto. 

such as the field devices. Alternatively, any or all of the Fieldbus devices may have 
their own power supplies or may be connected to external power supplies via 
separate wires. The Fieldbus protocol aUows many device/wire topologies, 
including multiple devices being connected to the same pair of virires. point-to^wint 
connections in which each device is connected to a controller or a host via a 
separate two-vrtre pair (similar to typical 4-20 mA analog systems), and tree or 
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"spur" connections in which each device is connected to a common point in a two* 
wire bus which may be, for exan4>Ie, a junction box or a termination area in one of 
the field devices within a process control network. 

Data may be sent over the bus segments at any of a number of different 
ccMnmunication baud rates or speeds accordiqg to the Fieldbus protocol. For 
example, the Fieldbus protocol provides a 31.25 Kbit/s communication rate (HI) or 
a 1.0 Mbit/s and/or a 2.5 Mbit/s (H2) communication rate, which will helically 
used for advanced process control, remote iDput/ouQ>ut, and high speed £acu>ry 
automation ai^lications: Likewise, data may be sent over the Fieldbus bus using 
voltage mode signaling or current mode signaling. The maximum length of ar^ 
Fieldbus bus or segment is ix>t stricdy limited but is, instead, determined by the 
commimication rate, cable type, wire size, bus power option, etc: 

The Fieldbus protocol classifies the devices tfiat can be connected to the bus 
into diree primary categories, namely, basic devices, liidc master devices, and 
bridge devices. Basic devices can communicate, that is, send and receive 
communication signals on or from the bus but are ix>t callable of controlling die 
order or timing of conrummication that occurs on the bus. Link master devices are 
devices that communicate over tte bus and are c^ble of controlling the flow of 
and the timing of communication signals on the btis. Bridge devices are devices 
configured to communicate on and to intercom^ct individual segments or branches 
of a Fieldbus bus to create larger process control networks. If desired, bridge 
devices may convert between different data speeds and/or different data signaling 
formats used on die diffoent s^ments of die bus, may amplify signals traveling 
between the segments of die bus, may filter the signals flowipg between the 
different segments of the bus and pass only those signals destined to be received by 
a device on one of die bus s^ments to wbkh the bridge is coiqiled and/or may take 
other actions necessary to link different segments of the bus. Bridge devices that 
connect bus segments that operate at different q>eeds must have link master 
capabilities at the lower speed segment side of the bridge. 

Each of the Fieldbus devices is capable of communicatiiig over the bus and, 
importandy, is capable of independendy performintg one or more process control 
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fimctions using data acquired by the device, from the process, or from a different 
device via comfflunication signals on the bus. Fieldbus devices are. therefore, 
capable of diiecdy mq>lementing portions of an overall control strategy which, in 
the past, were performed by a centralized digital controller. To perform control 
functions, each FieWbus device inchidcs one or more standardized -blocks" which 
are implemented in a microprocessor wiflim the device. In particular, each Fieldbus 
device includes one resource block, zero or more function blocks, and zero or more 
transducer blocks. These blocks are referred to as block objects. 

A resource block stores and communicates device specific data pertaining to 
s«ne of the characteristics of a Fieldbus device includmg. for example, a device 
Orpe. a device revision indication, and indications of where other device specific 
information may be obtained within a memory of the device. WhUe different device 

manufecnirers may store different types of data in the resource block of a field 
device, each field device conforming tt> the Fiddbus protocol includes a resou^ 

block diat stores some data. 

A fimction block defines and implements an input fimction. an output 
function or a control function associated with the field device and, thus, function 
blocks are generaUy referred to as input, output, and control function blocks. 
However, other categories of function blocks such as hybrid function blocks may 
exist or may be developed in the fimire. Each input or output function block 
produces at least one process control input (such as a process variable from a 
process measurement device) or process control ou^ (such as a valve position 
sem to an acmation device) while each control fimction block uses an algorithm 
(which may be proprietary in nature) to produce one or more process outputs from 
one or more process inputs and control inputs. Examples of standard function 
blocks include analog input (AI). analog output (AO), bias (B). control setedor 
iCS), discrete input (DI). discrete output (DO), manual loader (ML). 
propi>rtional/derivative (PD), propoitional/integnd/derivative (PID). ratio (RA). and 
signal selector (SS) function blocks. However, other types of function blocks exist 
and new types of function blocks may be defined or «;reated to operate in to^ 

Heldbus enviroimieiit. 
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A transducer block couples the inputs and outputs of a function block to 
local hardware devices, such as sensors and device actuators, to enable function 
blocks to read the ouq[>uts of local sensors and to command local devices to perform 
one or more functions such as moving a valve meniber. Transducer blocks 
typically contain information that is necessaiy to interpret signals delivered by a 
local device and to properly control local hardware devices including, for ejcamplc^ 
information identifying the type of a local device, calibration information associated 
with a local device, etc. A single transducer block is typically associated with each 
input or ou^ut function block. 

Most function blocks are capable of gei^rating alarm or event indications 
based on predetermined criteria and are equable of operatiqg differently in different 
modes. Generally qpeaking, function blods may operate in an automatic mode, in 
which, for exanqile, the algorithm of a function block operates automatically; an 
operator mode in which the input or ouQnit of a function blodc is controlled 
manually; an out-of-service mode in which die block does not operate; a cascade 
mode in whidi the operation of the block is affected from (determined by) the 
output of a different block; and one or more remote modes in which a remote 
conq>uter determines the mode of the blodc. However, other modes of operation 
exist in the Fieldbus protocol. 

Importantly, each block is capaUe of communicating with other blocks in 
die same or different field devices over the Fieldbus bus using standard message 
formats defined 1^ the Fieldbus protocol. As a result* combinations of function 
blocks (in the same or different devices) may communicate with eadi other to 
produce one or more decentralized control loops. Thus, for exanq>le, a PID 
function block in one field device may be oonnecled via the Fieldbus bus to receive 
an output of an AI function block in a second field device, to deliver data to an AO 
function block in third field device, and to receive an output of the AO function 
block as feedback to create a process control loop separate and apart from any 
centralized controller. In this manner, combinations of function blocks move 
control functions out of a centralized DCS environment, which allows DCS multi- 
function controllers to perform siqpervisory or coordinatinig functions. 
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Furthennoic. function blocks allow the use of a graphical, block-oriented strucnire 
for easy configuration of a process and enable the distribution of functions among 
field devices from different suppliers because these blocks use a consistent 

ronmmTiiciit^o^^ protocol. 

In addition to containing and implementing block objects , each field device 
includes one or more other objects mchiding link objects, trend objects, alert 
objects, and view objects. Link objects define the links between the inputs and 
ouQMits of blocks (such as function blocks) both internal to the field device and 
across the Fieldbui biiS. Trend objects allow local trending of function block 
parameters for access by oflier devices such as a host or a controUer. Trend objects 

retain short-term historical data pertaining to some, for example, function block 
paraxneter and report this data to other devices or fimction blocks via the Fieldbu^ 
bus in an asynchronous manner. Alert objects report alarms and events over the 
Fieldbus bus: These alarms or events may relate to any event that occurs within a 
device or one of the blocks of a device. View objects are predefined groupings of 
block parameters used in standard human/machine interfiicii« and may be sent to 

other devices using asynchronous communications for viewing from time to tinae. 
Referring now to Fig. 2, three Fieldbus devices, which may be, for 

example, any of the field devices 43-50 of Fig. 1, are iUustrated as inchiding 

resource blocks 58. functton btocks 60, 61 or 62 and transducer blocks 63 and 64. 

In the first device, the function bkK* 60 (which may be an iiqmt fimction b^ 

coupled through the transducer block 63 to a sensor 65 . which may be. for 
exanqjle. a temperature sensor, a set pomt indication sensor, etc. Inthesecond 

device, the function block 61 (which may be an output fimction block) is coupled 
through the transducer block 64 to an output device such as a valve 66. Inthethird 

device . the function block 62 (which may be a control function block) has a trend 
object 67 associated therewith for trending the input parameter of the function block 
62. 

Link objects 68 define the connections of block parameters of each of the 
associated blocks and alert objects 69 provide alarms or event notifications for the 
each of the associated blocks- View objects 70 are associated with each of tiie 

- 16- 



function blocks 60, 61 and 62 and include or group data lists for the function blocks 
with which fliey are associated. These lists contain information necessaiy for each 
of a set of diffeiwit defined views. Of course, the devices of Fig. 2 are merely 
aumpUay and other numbers of and types of block objects, link objects, alert 
objects, trend otgects, and view olgects may be provided in any field device. 

To inq>lement and perfoxm commimfcation and control activiiies, tiie 
Fieldbus protocol uses three general categories of technrfogy identified as a 
physical Uiyer. a communication "stack," and a user layer. The user layer includes 
the control and configuratira functions provided in the form of blocks (such as 
function blocks) and objects withm any particular process control device or field 
device. The user layer is typically designed in a proprietary manner by the device 
manufacturer but must be capable of receiving and sending messages according to 
the standard message format defined by the FieMbus protocol and of being 
configured lyy a user in standard manners. The physical layer and the 
onnmunication stack are necessary to effect communicatira b«wecn.dififerent 
blocks of different field devices in a standardized manner using a two-wire bus and 
may be modeled by the weU-known Open Systems Interconnect (OSI) layered 
communication model. 

The physical layer, which corresponds to OSI layer 1, is embedded in each 
fieM device and die bus and operates to convert electromagnetic signals received 
from the Fieldbus transmission medium (the two-wire Fieldbus bus) into messages 
capable of being used by die cOTununication stack of the fidd device. The idiyskal 
layer may be thought of as dK Fieldbus bus aiMl the electiximagnetic signals present 
on the bus at the ir^Nits and oatpats of the field devues. 

The communication stack, which is present in each Fieldbus device, includes 
a data link layer, which corresponds to OSI layer 2, a Fieldbus access sublayer, and 
a Fieldbus message specification layer. The user layer of the Fieldbus protocol is a 
layer diat is not defined in die OSI protocol. Bach layer in die communication stack 
is responsible fior encoding or decodmg a portion of the message or signal that is 
transmitted on die Fieldbus bus. As a result, each layer of die communication stack 
adds or removes certain portions of die Rddbus signal such as preambles, start 
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delimiters, and end delimiters and. in some cases, decodes the stripped portions of 
tbe Fieldbus signal to identify where the rest of the signal or message should be sent 
or if the signal should be discarded because, for example, U contains a message or 
data for function blocks that are not within the receiving field device. 

The data liidc layer controls transmission of messages onto the Fieldbus bus 
and manages access to the bus according to a deterministic centralized bus scheduler 

caUed a link active scheduler, to be described in more detail below. Thedatalink 
layer removes a preamble from the signals on the transmission medium and may use 
«he received preamble to synchronize the internal clock of the field device with the 
incoming Fieldbus signal. likewise, the data link layer converts messages on the 
cominunication stack into physkal Fieldbus signals and «»codes the* 

clock information to produce a " synchronous serial* signal having a proper 
preamble for transmission on the two-wire bus or loop. During the dccodmg 
process, die data link layer recognizes special codes within the prean*le. such « 

start delimiters and end delimiters, to identify the beginning and the end of a 
particular Fieldbus message and may perform a checksum to verify the miegrity of 
the signal or message received from the bus. Likewise, the data Imk layer transmits 
Fieldbus signals on the bus by adding start and end delimiters to messages on die 
communication stack and placing tiiese signals on dw transmission medium at die 
appr o pri ate time. 

The FieMbus message specification layer aUows die user layer (i.e.. die 
function blocks, objects, etc. of a field device) to communicate across die bus using 
a standard set of message formats and describes die communication servfccs. 

message formats , and protocol behaviors required to build messages to be placed 
onto die communication stack and to be provided to die user layer. Becausethe 
Fieldbus message specification layer suppUes standardized communications for die 
user layer, specific Fieldbus message specification communication services are 
defined for each type of object described above. For example, die Fieldbus 
message specification layer includes object dictionary services which allows a user 
to read an object dfctionary of a device. The object dictionary stores object 
descriptions diat describe or identify each of die objects (such as block objecte) of a 
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device. The Fieldbus message specification layer also provides variable access 
services which allows a user to read and change commxmication relationships, 
known as virtual communication relationshq>s (VCRs) described hereinafter, 
associated with one or more objects of a device. Still further, the Fieldbus message 
5 specification layer provides context managenamt, variable access services, event 
services, iq)load and download services^ and prpgram invocation services, all of 
which are well known in the Fieldbus protocol and, therefore, will not be described 
in more detail herein. The Fieldbus access sublayer maps the Fieldbus message 
specification layer into die data link layer. 

10 To allow or enable operation of these layers^ each Fieldbus device includes a 

management infomiation base (NOB), which is a database that stores VCRs, 
dynamic variables, statistics, timing sdiedules, function block execution timing 
schedules and device tag a«d addreff information. Of course, the information 
within the MIB may be accessed or changed at any time using standard Fieldbus 

IS messages or commands. Furtfa eimoie , a device description is usually provided with 
eadi device to give a user or a host an extended view of the information in the 
VFD. A device descriptkm, wfaidi must ^ically be tokenized to be used by a 
host, stores informaticm needed for die host to understand die meaning of the data in 
the VFDs of a device. 

20 As will be uiKlerstood, to in4>leinent any control strategy using function 

blocks distributed throughout a process control network, the execution of the 
function blocks must be precisely scheduled with respect to the execution of other 
function blocks in a particular control loop. Likewise, communication between 
different function blocks must be precisely scheduled on the bus so that the proper 

25 data is provided to each function block before diat block executes. 

The way in which different field devices (and different blocks within field 
devices) communicate over the Fieldbus transmission medium will now be 
described. For communication to occur, one of die link master devices on each 
segment of the Fieldbus loop operates as a link active scheduler (LAS) which 
. 30 actively schedules and contrc^ communication on the associated segment of die 
bus. The LAS for each segment of the bus stores and executes a communication 
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schedule (a link active schedule) containing the times that each function block of 
each device is scheduled to start periodic communication activiQr on the bus and the 
lei^gth of time for whicA this communication activity is to occur. While diere may 
be one and only one active LAS device on each segniCTt of tihe bus, other link 
S master devices may serve as backup LASs and become active if, for example, the 
current LAS fails. Basic devices do not have the capability to become an LAS at 
any time. 

Generally speaking, communication activities over the bus are divided into 
lepeatiqg macrocycles which define the synchronous communication schedule for 

10 the bus. A device may be active, i.e., send data to and receive data from any 

segment of the bus, even if it is physically connected to a different segment of the 
bus, through coordinated operation of the bridges and die LASs on die bus. 

During eadi macrocycle, eadi of the function blocks active on a particular 
segment of the bus executes, usually at a different, but precisely scheduled 

IS (synchronous) time. If the function block has an ouq>ut paranieter that is linked to 
another parameter external to the device, the function block publishes its output data 
at a precisely scheduled time in response to a compel data command generated by 
the LAS. Preferably, each function block is scheduled to publish its ouq>ut data 
shortly after the end of the execution period of the function block. Furthermore, 

20 the data publishiAg times of the different function blocks are scheduled soially so 
that no two function blocks on a particular segment of the bus publish data at the 
same time. During the time that synchronous communication is not occurring, each 
field device is alloived, in turn, to transmit alarm data, view data, etc. in an 
asynchronous manner using token driven communications. The execution schedule 

25 is stored in die management information base (MIB), the execution times of the 
blocks are stored in the function blocks and the times for sending the compel data 
f^ ^TytandR fo cach of the devices on a segment of the bus are stored in the MIB of 
the LAS device for that segment. These times are ^ically stored as offset times 
because they identify the times at which a fimction block is to execute or send data 

30 as an ofEset from the beginnixig of an "absolute link schedule start time," which is 
known by all of the devices connected to the bus. 
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To effect communications during each macrocycle. the LAS sends a compel 
data command to each of the devices on associated bus segment according to the list 
of transmit times stored in the link active schedule. Upon receiving a compel data 
command, a function block of a device publishes its output data on the bus. 

5 Because each of the functions blocks is lypicaMy s d ie duled to execute so that 

execution of tiiat block is conq>leied shortly before the block is scheduled to receive 
a compel data command, the data published in reqmnse to a compel data command 
should be the most recent ouqmt data of the function block. However, if a function 
blodc is executing slowly and has not huched new outputs when it receives flie 

10 compel data command, the function block publishes the output data generated 
during the last run of the function block. 

During periods in which compel data publications ate i^t scheduled, the 
LAS may cause asynchronous communication activities to occur. To effect 
asynchronous communication, the LAS sends a pass token message to a particular 

15 flelddevice. When a field device receives a pass token message, tiiat field device 
has full access to.tiie bus (or a segment thereoQ and can send as3fncfaronpus 
messages, such as alarm messages, trend data, operator set point changes, etc. until 
the messages aie complete or until a maximum allotted *tokm hold time" has 
expired. Thereafter the field device releases the bus (or any particular segment 

20 thereof) and the LAS sends a pass token message to anoflier device. This process 
npeass until the LAS is either scheduled to send a compel data command to effect 
synchronous communication or tte LAS has network maintenance to perform. Of 
course, depending on tiie amount of message traffic and tiie number of devices and 
blocks coiq>led to aqy particular segment of tiie bus, not evoy device may recave a 

25 pass token message during each macrocycle. 

Fig. 3 ilhistrales a timing schematic depicting dw thnes at which function 
blocks (labeled AIuww, PIDuwpi. ^voon* AOuk,p„ SSux>n> »od PIDux>n) execute 
during each macrocycle of a bus segment and the times at which synchronous 
communications occur during eadi macrocycle associated with the bus segment. In 

30 dietimingscheduleofFig. 3, time is indicated on the horizontai axis and activities 
associated with the different function blocks are iUustrated on the vertical axis. The 



control loop (which is aft)itrary for the purposes of this discussion) in which each of 
the functions blocks operates is identified in Fig. 3 as a subscript designation. Thus 
AIloopi refers to the AI function block of» for exanq>le, a transmitter (grating 
within a first control loop, PIDijoon refers to the PID function block in, for 
S example, a positioner/valve operating within the first control loop, etc. The block 
execution period of each of the illustrated function blocks is depicted by a cross- 
hatched box while each scheduled synchronous communication is identified by a 
vertical bar in Fig. 3. 

Thus, according to the timing ^hedule of Fig. 3, during any particular 

10 macrocycle of the bus segment, the AIuoopi fimction block executes first for the time 
period specified by the box 71. Then, during the time period indicated the 
vertical bar 72, the output of die AIux>fi function blo^ is published <m d^ bus 
segment in response to a compel data cOTomand fixxm the LAS for the bus segment. 
Likewise, the boxes 74, 76, 78, 80, and 81 indicate die executton times of the 

15 function blocks PIDu^pi. AIloopz* AO^x)?!, SSloopj, and PIDu)op3. respectively 

(which are different for each of the different blocks), while the vertical bars 82, 84, 
86, 88 and 89 iiKiicate the times that the function blocks PIDloopi^ AIloopi* 
AOi^oopi, SSu)OF2 ^ PII>ijoop3' respectively, publish data on the bus segment. 

As will be apparent, the timing schematic of Fig. 3 also illustrates the times 

20 available for asynchronous communication activities^ which may occur duripg die 
execution times of any of the function blocks and during ilie time at the end of the 
macrocycle during which no function blocks are executiqg and when no 
synchronous communication is taking place on the bus segment. Of course, if 
desired, different function blocks can be intentionally scheduled to execute at the 

25 same time and not all function blocks must publish data on the bus if, for exanq)Ie, 
no other device subscribes to the data produced by a function block. 

Field devices are able to publish or transmit data and messages over the 
Fieldbus bus using one of three virtual conmnmication relationships (VCRs) defined 
in the Fieldbus access sublayer of tte stack of eadti field cfevioe. A client/server 

30 VCR is used for queued, unscheduled, user initiated, one to one, communications 
between devices on the bus. Such qu^ied messages are sent and received in the 
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order submitted for transmission* according to their priority, without overwriting 
previous messages. Thus, a field device may use a client/server VCR when it 
receives a pass token message from an LAS to send a request message to anodier 
device on the Fieldbus bus. The requester is called die "client" and the device Oat 
5 receives the request is called Ae "saver." The server sends a response when it 
receives a pass token message from the LAS. The client/server VCR is used, for 
example, to effect opaztor initiated requests sudh as set point changes, tuning 
parameter access and changes, alarm acknowledgments, and device uploads and 
downloads. 

10 A report distribution VCR is used for queued, unscheduled, user initiated, 

one to many communications. For example, when a field device with an event or a 
trend report receives a pass toten from an LAS, that field device sends its message 
to a "group address" defined in the Fieldbus atcess sublayer of the communication 
stack of that device. Devices that are ccmfigured to listra on Aat VCR will receive 

15 the report. The rqwrt distribution VCR type is QrpicaUy used by FieldbiK dev^ 
to send alarm notifications to operator consoles. 

A publisher/subscriber VCR type is used for buffered, one to many 
communications. Buffered communications are ones diat store and send only the 
latest version of the data and, thus, new data completely overwrites previous data. 

20 Function block ouqnits, for example, comprise buffered data. A "publisher" field 
device publishes or broadcasts a message using the publisher/subscriber VCR type 
tt> all of die "subscriber" field devices on die Fieldbus bus when the publisher 
device receives a conqpel data message fran the LAS or firom a subscriber device. 
The publisher/subscriber relationships are predetermined and are defined and stored 

25 within die Fieldbus access sublayer of the communication stack of each field device. 

To assure proper communication activities over the Fieldbus bus, each LAS 
periodically sends a time distribution message to all of the field devices cormected 
to a segment of the bus, which enables the receivn^g devices to adjust their local 
datalink time to be in synduonization widi one ariodier. Between these 

30 synchronization messages, clock time is indq)eiidently maintained in each device 
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based on its own internal clock. Clock synchronization allows the field devices to 
synchronize fonction block execution with the network. 

As will be understood from the discussion of the Fieldbus communication 
protocol given above, communicating with any particular device or function block 
located in the Fieldbus section of fl« process control network 10, i .e . , comiected to 
the bus 42 . requires a detailed knowledge of how communication is generally 
effected within the Fieldbus protocol as weU as a consideration of and knowledge of 
the how the Fieldbus bus 42 is particularly set up and when communications 
associated therewith are scheduled and allowed. This, in mm. makes it difficult for 
a designer of the process amtrol routine implemented within the controUer 12 to 
implement and schedule commmncations with the devices withm the Fieldbus 
section of the process control network. i.e.. the devices comiected to the bus 42. 
Fttrthermoie . because standard or regular communications between function blocks 
occur in a synchronous manner over die bus 42. the controller 12 must be 

1 5 configured to receive all of these commmncations or at least the ones it needs to 
perform its control routine. It can be a daunting task on the part of the controller 
12 to coordinate receipt and storage of all of die information flowing on die bus 42 
in a way that can be efficientiy used by die controller 12 to effect control of die 
entire process 19. Furthermore, to receive information that is not sent 

20 synchronously over the bus 42. the comroller 12 must send a request for that 

information which, as explained above, is sent asynchronously over die bus 42. 
Because dieie is no way for die coniroUer 12 to determine or effect when die 
asynchronous request wiU be delivered to die a^ropriate device (b^ 

of diis request is direcdy effected by die oflier asynchronous communications 
occurring on die bus 42), die controller 12 may receive information that is out-of- 
date by die time it reaches d« controUer 12. Likewise, die contioUcr 12 has no 
way of determining what such data is or was at a specific time, which may be 

important in controlling odier devices widiin die process 19 not comiected to die 
bus42. Still further, it may be difficult or in^iossible for die controller 12 to 
xcceive in^Kirtant information pertaining to die stams of a device or a function block 



25 



30 



-24- 



within the Fieldbus section of the process 19, such as alarms generated by those 
function blocks. • 

To overcome Aese problems, the controller 12 may be designed to use 
shadow function blocks to inq>Iraient ccmmmnication with tte devices and function 
S blocks within the Fieldbus section of the process control network 10: More 

particularly, the control routine within die controller 12 may communicate directly 
with a shadow function block within the controller 12 which then automatically 
communicates with an associated actual external function blodc within a field device 
connected to the bus 42. Theshadow function block within the controller 12 is 

10 configured to mirror the state of and the data associated with the actual external 
function block down within a device connected to the bus 42 so that it appears, to 
the process control routine within the controller 12, that the actual external function 
blodc is accessible without having to commomcate dirough the Fieldbus protocol 
ova the bus 42. In other words, it appears to the process control routine within the 

IS controller 12 that die actual fiincdon blodc is located widiin die process controller 
12 instead of down within an external field device ootmected 4o the bus 42 and the 
process control routine uses the shadow functk>n block as it uses other function 
blocks within the controller 12. 

Fig. 4 iUustrates a gr^hical dq>icdon of a process control loop or module 

20 100 associated with and implemented by the process control routine stored within 
the process controller 12. To inqilemeot control of the entire process 19, the 
process control routine within die controller 12 may inqplement many such loops or 
modules which may be interconnected in any desired manner. The depicted process 
control loop 100 includes a rqiresemation <tf an aspect (flow) of die process 101 

25 being controlled by rnnnber of controller blocks or units and, in particular, by a 
PID block 102 coupled to an AO block 104, a first AI blodc 106 and a second A! 
block 108. Each of the blocks 102, 104 and 106 is a gr^hical depiction of a 
control sub-routine (or object widiin an object oriented programming environment) 
associated with die process control routine stored within the controller 12, 

30 configured accordii^ to a controller protocol associated widi the controller 12 and 
used to implement a portion of an overall control strategy widi respect to the 
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process 101. Each of the blocks of the process control routine 100 includes inputs 
and outputs (illustrated by entries on tl» left and right sides of flie blocks 
lespectivdy) and may iiKhide a control algorithm which perfbnns some ccmtrol 
function. Intetconnections or links between the function blocks are Ulustrated as 
lines runmngfiom an output of one blodc to an input of another block. Theselmks 
represent the manner in which communication is implemented between the 
individual blocks within the control routine or module to perform a process control 
loop accordmg to a controUer protocol. Thus, the depiction of Fig. 4 iUustrates not 
only the elements of the control loop being performed but also the manner in which 
ibs process control routine within the controller 12 is designed to implement this 
loop. The process control routine can be changed or reconfigured automaticaUy by 
moving the between blocks, adding or deleting blocks therefrom, etc. as is 
performed by the DeltaV process controUer. 

The PID function block 102 illustrated m Fig. 4 hicludes an algorithm 
(implemented by the conttoUer 12) which perfbnns. for example, a 
proportional/integral/derivative control calculation based on the ii^iuts it receives 
from the AI blocks 106 and 108 and the AO block 104 and provides an output 
control signal to the AO block 104 which, m turn, causes a device (such as a valve) 
within the process 101 to perform a function, like causing a valve to move to 
increase fluid flow. The AO block 104 may be associated with and control an 
acnial valve, e.g.. the valve 28 of Fig. 1, via the I/O device 20 and the 4-20 mA 
communication line 38. The AO block 104 receives a measuremem of the actual 
poshion of the valve and provides this measurement as feedback to the PID fimction 
block 102 via the link 110. Stffl further, the PID function block 102 receives inputs 
from the AI block 106. which is associated with, for example, a sensor such as a 
tenq>erature sensor located within the process 19. This sensor may be, for 
example, the sensor 34 of Fig. 1. in which case the AI block 106 receives sensor 
measurements via the I/O device 22 usmg standard c o m nw m ic a t i o ns. Such a 
connection is illustrated in Fig. 4 1^ the Imk between the ou^t marked "flow" m 
the process 101 and the input to tiie AI block 106 marked "sinnilaie_m". The 
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processing and control of the infonnation associated with the PID function block 
102, the AO block 104 and the AI block 106 is performed within the controller 12. 

Generally speaking, within the DeltaV control system, i.e.. using the DeltaV 
controller configuration protocol, each of tiie blocks 102. 104 and 106 is 
5 specificaUy configured to supponaU of the infonnation and data associated with 

sinular function blocks in die Fiddbus protocol and tinis. for all intents and 
purposes, is very similar to a function block widiin die Keldbus protocol except 
that the control fimctions are perfoinied 1^ die cmtral processor 12 and infonnation 
is received from and delivered to particular field devices via standard 

10 communication lines from tbt process controller 12. Thus, the portions of Ae 
control routine depicted in Fig. 4 including the blocks 102. 104 and 106 are 
cunently provided in the DeltaV environmeiit and are kno^. 

To support Fieldbus int^ratim widiin the controller 12, the.foUowing 
ai^voach jnay be takm usiiig a Delta-V cooixol system (or other centralized control 

IS system) in \i^iich die basest of fiuicti<m blocks used in die coiitrol system is 
similar to thox d^ined by die Reldbus jwotpcol. The external Fieldbus or 
manufacuirar specific function blocks are indivklually assigned to ocecute in 
conjunction with the control system (or as part of die control system) and die 
function blocks in the FiekltHis devices are reflected in control system as shadow 

20 function blocks that support internal and external refermces as ttK>ugh the external 
function blocks reside in die control ^sinn. The control system automatically 
iqidates the dynamic and static parameters of tte shadow function block and passes 
change requests to the appropriate external function blocks using the shadow 
function blocks. Alarms detected in die ejoeinal devices (or function blocks) are 

25 reflected in the shadow function blocks and are incorporated into the alarm 
processing of the control system. Of oomse, die shadow fiinction block 
communicates with the external function blocks using the communication protocol 
associated with the external fum^tion Modes which may be. and Qrpically is, 
different than the controller configuration protocol used by die controller to 

30 implement communications between die fimction blocks internal to die controller. 
Also, links between internal and external fimction Mocks may be defined by the 
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user in a manner which is independent of where the function block resides. As a 
result, during control definition and on-line diagnostics, function blocks appear the 
same wbedier they are internal (and reside in the control system) or are external 
(and reside in a Fieldbus device). 
5 Thus, according to die present invention, ttie AI block 108, wtdch is 

depicted in Fig. 4 as being similar to the AI block 106, is actually a shadow 
function block that is configured to communicate witii an external function block 
112 located wifliin, for exaiiq>le, the sensor 48 connected to the Fieldbus 42 of Fig. 
1. The shadow function blcKk 108 provides measured or other signals associated 

10 with the external function block 112 to the PID block 102 via links established 
therebetween. To iiidicate that the block 108 is a shadow function block asso^ 
widi an external function blo^ 112 and commimicates therewith using die 
communication protocol of the external function block 112, the block 108 is 
depicted as having a dotted line connected to the AI function block 112 within die 

15 Fieldbus device 48. However, die shadow function block 108 may be d^icted as 
having the device tag and/or block name at the bottom thereof, or may be depicted 
in any other desired manner, it being understood that the manner in which the 
shadow fiinction block is depicted to a user is not critical to the operation of the 
shadow function block. Furthermore, the inputs and ouq>uts associated with the AI 

20 function block 112 are delivered withm the Fieldbus network according to the way 
in which that network has been configured. 

While the shadow function block 108 accesses and mirrors all or most of the 
information associated widi and/or generated by the actual function block 112, any 
processing that takes place with respect to die AI function block 112 (or ai^r odier 

25 function block for which a shadow function block exists) does so down in the 

external device, not in the shadow function block 108 or even in the controller 12. 
As a result, the shadow function block 108 can be thought of as a conduit of 
information between the PID block 102 (or any odier block withm the centralized 
controller 12) and the actual function blodc 112. The shadow function block 108 is 

30 not a function block that is fully operational hy the controller 12 in die srase that 
the AI block 106 and PID block 102 are operational by die controller 12 because 
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the shadow function block 108 merely mirrors the information within the actual 
external function block 112 or otiierwise provides conmmnication between the 
controller 12 and die actual external function block 112. None-the-less, by proper 
operation of the shadow function block, the controller 12 can control and 
5 communicate widi the actual furction block 112 as if it were being fully 

inqplemented widiin the controller 12. For exanq>le, by communicating with the 
shadow function block 108 vsing the controller configuration protocol, die proces 
control routine widiin the controller 12 can receive iqvto-date information from the 
function blo(^ 112 and can send commands to the function blodc^^^n^ 

10 - possible without the worrying about where the actual function block 1 12 is located 
or how to effect communications widi the actual function block 1 12. Instead, the 
communications between the actual function block 112 and the shadow function 
block 108 occur automatically without intervention by the process control routine, 
which needs only to take the steps it typically takes to implement ccmimimications 

IS between control or function blocks located within ihe controller 12. In this manner, 
the shadow function block enables a controller, vMtiti is iiiq>lementing function 
blocks within the controller, to utilize and incorporate function blocks that use 
differrat communication or configuration protocols and diat are not within die 
controller but that are, instead, located in and implemented by an external device, 

20 such as a microprocessor based field device located within a process environment. 
This added capability is accomplished transparentiy to the controller 12 so that, 
once the shadow function block is set up in die controller 12, the control routine 
does not need to track where the actual function block is located or perform 
cosqilex communications or database manipulations in order to utilize the external 

25 function block 112. 

As will be understood, the shadow function block 108 stores the inputs and 
ouqiuts and the parametric updates associated with the AI function block 112 in a 
database in the controller 12 in any desired format but, preferably stores these in 
the same or similar format as the information associated with the control blocks 

30 . implemented by the controller, i.e., usiiig the controller configuration protocol. 
This makes communication with the shactow function block 108 transparent to the 
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controller 12, i.e., the process control routine 100 provides communication with 
respect to the shadow function block 108 (and thus the actual function block 112) 
via links in the same manner that it provides communication with respect to the 
ottkCT function blocks 104 and 106. While it is desirable to have the function blocks 
5 within the controller 12 logically configured to siq>port all (or most) of the 

information supported by the decentralized (or external) process control network (as 
is the case with the DeltaV controller and the Fieldbus communication protocol), 
this configuration is not necessary. In fact, any controller semp can be supported 
using the shadow function block disclosed herein by mapping the data siqiported in 

10 and available from the external fimction block to the data used by and available in 
the controller routine. 

Graerally speaking, to effect operation of die shadow function block 108 in 
a Fieldbus network, die actual function block 112 is configured to send or publish 
linted data (i.e., data that is linked to another block within the controller 12 via one 

15 of the links illustrated in Fig. 4) to the process controller 12 via the inter&ce card 
40 using the publisher/subscriber VCR (i.e., synchronous conmmnications) in the 
Fieldbus communication protocol. Other non-linked data associated with the actual 
function block 1 12 is delivered to the interface card 40 using asynchronous 
communications, using, for exanqple, the view object or alert object functicms 

20 within the Fieldbus protocol whidi occurs at the module scan rate of the control 
module within the controller 12. Typically, therefore, linked data is sent to die 
controller 12 from the function block 112 at a mudi faster rate than other (less time 
sensitive) data. Conversely, linked data sent by a block within die controller 12 to 
the shadow function block 108 is imn^diately forwarded to the interface device 40 

25 where it is then published on the Fieldbus bus 42 using standard synchronous 
communications. 

The information sent by the actual function block 1 12 is automatically placed 
in die shadow function block 108 and is thus available to the control routine in the 
controller 12 at any time. To effect this operation, the interface card 40 (whidi 
30 may be part of a communication port of die shadow function block) subsoribes to 
the published link parameter data produced by the function block 112 and forwards 

-30- 



this information to the process controller 12 at the rate defii^ by the execution rate 
of the function block within macrocycle of the Fieldbus segment to which the 
external function block 112 is connected. Likewise, the interface card 40 (which is 
^ically die LAS of the Fieldbus segment) obtains view objects and/or alert objects 
of the actual funcdon block at the rate defined by the scan rate of the controller 
module in which die shadow funcdcm block 108 resides, i.e., at the rate that the 
control routine 100 in the controller 12 implements die blocks associated therewidi. 
As is known, the Fieldbm protocol iiK:ludes four types of view objects which store 
the normally dynamic (view object 1), normally static (view object 2), all dynamic 
(view object 3) and all static (view object 4) variables. The interface card 40 is 
configured to receive automatically on a periodic basis or by sending out a request 
for such information, the all dynamic view object 3, whidi includes the values for 
allof the dynainic variables associated widi the actual function block 112. Upon 
receiving this view object informaticm, the imerftce card 40 stores the information 
in a database accessible by die shadow function blodc, and the shadow function 
block 108 updates the variables which have cfaaiiged diereby makir^ these variable 
values available to the process control routine within the controller 12. If one of 
the dynamic variables (the static revision variable) indicates a change to a static 
variable, the shadow function block or software within the interface card 40 may 
request that the view object 4 (all static variables) be sent to the shadow function 
block 108 to update the static variables. In die prefmed embodiment, the HI 
interface card 40 continually receives view object 3 at the module scan rate of the 
control module 100 within the controller 12. 

As noted above, the controller 12 (or aiiy function block thereof) can send . 
commands to the actual function blodc 112 widiin die Fieldbus network via die 
shadow function block 108 by merely changing a parameter within the shadow 
function block 108. This parameter chaise is automatically sent down to the AI 
function block 112 via an output of the shadow function block 108 where it is used 
to change the configuration of die AI function block 112. While the data change or 
write command is not made in die actual function block 112 at the exact same time, 
that it is received by the shadow function block 108, from the standpoint of the 
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controller 12, this change occurs very quickly and is reflected back up in the 
shadow function block 108 when the change has actuaUy been made. This 
operation aUows the controller 12 and, specifically, the PID function block 102 
wiflim the controUcr 12 to cffi«t a change by merely writing that diangc i^^ 
5 memory location associated wifli the diadow function block 108 and havi^ 
communication done automaticaUy thereafter without having to perform any 
specialized communication activities necessary for getting data into and out of flie 
Fieldbus network. 

Besides input and output parametric data, other types of data such as mode 
10 and stanis data may be communicated between a controUer function block (i.e.. an 
internal function block) and the shadow function block 108 as weU as between the 
shadow function block 108 and the acnial external function block 112. Ofcourse. 

this infonnalion is sent with the view object or alert object infonnation from the 
external function block 112 to the shadow function block 108. Likewise, such 

15- mode and sums data may be delivered to the shadow function block 108 from an 
imemal function block within the controller 12 and that data may then be forwarded 
to the external function block 112 for use. The status parameter of a ftmction block 
typically mdicates the quality of the measurement or data bemg provided by the 
function block and may provide reasons why a poor quality exists. It may also 

20 indicate a limit, such as a high or low limit for which the data may take. Typically, 
the mode parameter indicates what mode the ftmction block is in, which may be. for 
exanq>te. a manual mode, an automatic mode or a cascade mode as defined by the 

Fieldbus protocol. 

StiU fiirther, alarm detection based on alarms generated in the acoial external 
25 ftmction block is provided because events and reports are automaticaUy generated 
by the external ftmction block as dynamic parameters whidi are then provided 
through the view or alert objects to the shadow ftmction block 108. Asaresult. 

alann mfonnation pertaining to the external ftmction block may be viewed by and 
used 1^ the controller 12. 
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Of course, while the block 108 has been described herein as a shadow 
function block, any of the blocks within Fig. 4 could also or alternatively be 
shadow function blocks. 

The advantages associated with usiqg a shadow function block such as the 
shadow fui^on block 108 illustrated in Fig. 4 is that it allows the process control 
designer to be inclement control within a centralized process controller 12 using 
external fimction blocks, i.e., function blocks actually inq>lemented within a 
different device and subject to different communication protocols. With the shadow 
function block, the designer does not need tb worry that the external fiuH^tion block 
is associated with a different communication or control protocol or is located in a 
different device because the communication between the shadow function block and 
the external function block occurs automatically and transparently to the control 
routine. . Furthermore, once a shadow fuKtion block is inq>lemented and running, it 
is easy to model ^lat is happening widiin die entire process control system without 
needii^ to worry about whether actions are occurring within a Fieldbus or other 
external device or within the controller because the shadow function block makes it 
appear to the controller and to the user that the actual function block is being 
inQ>lemented in the controller, even though this is not really the case. 

When using a common fuiH:tion block set and shadow fimction blocks in the 
control system to reflect fimction blocks assigned to external devices, the control 
strategy may be initially designed widiout knowiqg whether a particular function 
block of that strategy will reside in the control system or in an external device and 
user applications may access shadow function blocks (which reflect or model the 
external function blocks) in exactly the same manner as they access control system 
function blocks. Also, alarms detected by die external device are fully integrated 
into the control system alarm processix^ through the shadow block, allowing these 
alarms to appear in exactly the same manner for external function blocks as for 
function blocks that reside in die control system. 

The configuration, inqilementation and use of a shadow function block will 
now be described in more detaO with reference to Figs. S-13. Fig. 5 illustrates the 
plqrsical setup of a portion of the process control network of Fig. 1 in more detail. 
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A user workstation 150, which may be any one of the PCs 14 of Fig. 1, is 
communicatively connected to the controller 12 which, in turn is connected through 
the interface card 40 to the field device 48 having the function block 1 12 therein. 
As ilhistrated in Fig. 5, the controller 12 has an upper portion 152 in which the 
control roatinB 100 (inchidiug the shadow function block 108) is in^lemented. and 
a lower portion which inchides a database 156 for storing input and output 
infonnation received ficom the inter&ce card 40 as well as other I/O cards. 
Generally speaking, the intei&ce card 40 is configured to auumiatically recMve 
linked data published by the function block 112 via dje publisher/subscriber VCR 
(at the published rate defined by the macrocycle of the Fieldbus bus 42) and to store 
this data in the lower database 156 where it is provided to the shadow function 
block 108 at the scan rale of the control module 100 within the ccaitroller 12. 
Likewise, the interfiice card 40 is configured to publish linked data generated by a 
function block within die controller 12 on die Fieldbus bus 40 using synchronous 
communfeations widiin die Fieldbus netwoik. Also, the inierfecc card 40 is 
configured to periodically request (using a^nchranous communications) view 
and/or alarm data from the function block 1 12 and stores this infonnation m die 
lower database 156 for delivery to die shadow function block 108 at the scan rate of 
the controller module 100. 

The interface card 40 and/or the database 156 may conq>rise, may be part 
of, or may be controUed by a communication port of the shadow fiinction block 108 
which implements communications between die shadow fiinction block 108 and die 
external function block 112. The communication port includes an input which 
receives data fiom die external fiinction block 112 using the communication 
protocol of die external function btock 1 12 and an output communicates widi 
die external function block 112 to send data (inchidiiig write commands) to the 
external function block 1 12 using die communication protocol of the external 
function block 112. Of course, the communication port of the shadow fiinction 
block 108 may be inqilemented m software and/or odier hardware in the controUer 
in addition to or in conjunction widi die mterface card 40 and die database 156. 
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To configure a control routine using a shadow function block, a user at the 
workstation ISO can use any standard tools, such as those provided with the Delta V 
control system, to anitiaUy configure the process control system. In general, the 
DeltaV configuration tools enable the user to display* configure and interconnect 
5 blocks, such as those illustrated in Fig. 4, to inq>lement or design one or more 
control loops or modules associated with the control routine. For the purpose of 
this discussion, tte control routine for controUipg a process may have any number 
of modules, each of which may have ai^ number of desired blocks therein 
inq)lementing any number of control loops. During the configuration or design of a 

10 process control module, the user may select the use of a function block (bat is 

located within a device external to the controller 12 (such as a function block within 
one of the Fieldbus devices of <he process control system). In this case, the 
configuration tool associated witibi the controller 12 may be designed to ask the user 
to specify the physical connections of die device to the controller 12 and other 

IS device and function block configuration information necessary to initially configure 
the device and/or the function block within the device according to die 
conmiunication protocol of die that device (e.g., the Fieldbus comnmnication 
protocol). The user may be pronq>ted to provide this information in any d^ired 
manner such as dut>ugh the use of dialog boxes. Of course, the exact information 

20 needed will depend on tte type of device and function block beii^ specified, as will 
be understood and known by those fiuniliar with device protocol being used, such as 
the Fieldbus protocol. 

One way of specifyiqg that a fimction block is to be in^lemented by a 
particular external device (such as a Fieldbus device) is by having the user specify 

2S that the function blodc located in an external device, using a browser (or other 

software) to list or depict the external devices connected to the controller and then 
selecting one of die listed external devices as die device in which the function block 
is to be implemented. Another way is to select the function block on the screen and 
then drag and drop that funcdon block onto a dqiicdon of a block in an external 

30 . device. Either of diese or any other desired acdpn may tell die configuration tool 
that the function blodc to be inqilemented is widiin die external device and cause the 
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Ifae inter&ce card 40 may send this device and segment status data to the controUer 
(or other device) for dia^iostic purposes. 

Furthermore, the interface card 40 can monitor tte communication and 
timmg stains of a Fiddbus segment for diagnostic purposes. In particular, the 

5 inter&ce card 40 may auto-subscribe to die data published 1^ the field devices on 
die Fieldbus bus, and may analyze die received data to determine, for exanqile, 
timnig problems or other problems on the Fieldbus bus. If desired, the interface 
card 40 may time stamp and store the inroming data, and tfwn keep statistics related 
to rftrh fiinction block or device connected to the bus and/or statistics related to a 

ID segment of die bus. The interface card 40 may, for exanqile, determine the 

nmmnum and maxitnum tinaes between updates for particular published data aiid 
may determine if diese times are widiin an allowable range to see if a 
communication problem exists. Ukewise, die inteifiu» card 40 can compare die 
times at which particular data is supposed to be published on the bus with the actual 

15 time sudi data is published on die bus, can motutor stale data counts for fonction 
blocks or devices and can keep any other desired statistics to delect timing or other 
communication errors on the bus. Of course any other published data may be 
monitored to determine communication ot timing inoblems on the bus. As noted 
above, die statistical information gen er a t e d or stored by die interface card 40 may 

20 be kept for any function block, device, or scgfxxsat of die bus and may be sent to or 
read fay die controller (or any other device) for diagnostic purposes. 

F|g. 6 illustrates a flow chart 200 wtach indicates die way in vrbich a 
shadow fonction block widiin the controller 12 may be set iq>. While the flow 
charts of Figs. 6-12 ilhistrate a mmiber of blocks, it will be understood that these 

25 blocks merely indicate die a sequence of steps io be performed and that die st^ 
may be performed in software or in any other desired manner. The flow chart 
blo^ of Hgs. 6-12 do not, however, necessarily rqnesent fonction blocks or 
controller blocks similar to die foiKtion blodcs illustrated in Fig. 4. 

At a block 201, die controller 12 reodves a module installaticm scxipt tnm 

30 dieuserwotkstaticm, wbidimaybeonBofdiePCs 14of ing. 1. Tbemodule 

installation script is created by die configuration tool run by die user workstation 
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and includes all of the infonnation needed to set up the objects (in an object- 
oriented programming language) associated with the function blocks of a control 
module in the conuolkr 12. That is. the installation script configures the blocks 
(such as the fimction blocks associated with the control module 100 of Fig. 4) a^ 
the interconnections between those blocks defined by the links. Of course, all of 
this information is provided by the user while usii« the configuration t^^^ Whena 
function block is to be implemented by an external function block, such as one in a 
field device, a block 202 creates a shadow function block within the controller 12 
by treating an object (within an object oriented programming language) that is. , 
similar to the function blocks for other devices located withm the controller except 
that it does not perform ai^ control fimctions. Whfle the shadow function blocks 

are preferably created as an object in an 6bject-«iented programming enviromnent. 
ttey n»y be created using aiiy other programming cnviromnent associated witii or 

used by tfae controller 12. 

When setting up a shadow fimction block, die block 202 causes the interface 

card 40 to scan die actual function blodc widiin tfae Fieldbus device and obtain 
information from die actual function block diat is needed to initiaUy configure die 
shadow function block. Furtiiermore, tiie block 202 establishes the database 
locations widun die lower database 156 of the controller 12 to which die inlerfece 
card 40 should place view object and alert object data as well as linked parameter 
data obtained from die actual fimction block. The block 202 also informs die 
itterfiwe 40 how often to request view object and alert objea information based on 

the scan rate of the module 100. 

After die block 2<B creates a shadow fimction block in die controUer and 

identifies die appropriate interconnections between die database 156. die shadow 
fiuiction block 108 and die interface card 40 . a block 203 configures die lower 
database 156 to provide die stored linked parameter data (i.e.. diat obtained by die 
interface card 40 using die synchronous subscriber/publisher VCR) to die shadow 
finiction block instead of die data obtained for die linked parameters using die v^ 

object operation. This is necessary to assure die most recent data for die linked 

parameters (i.e.. diat obtained by die synchronous communications in die Fieldbus 
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network) is provided to the shadow function block 108 instead of the data obtaii^ 
for those parameters obtained using the view list operation (which occurs 
asynchronously). 

When a control module that uses a shadow function block is initially 
configured, the Fieldbus comnmnicadon networic must also be configured to support 
the necessary ^imchionous and asynchronous commuinications between the actual 
function block 112 and the shadow function block 108. Figs. 7-10 iUustrate 
flowcharts depicting the stqps involved in configuring the Fieldbus netwoik to 
support shadow function blodcs. While Figs. 7^10 are illustrated as separate 
flowhcarts, they can be peifoi med simultaneously or nearly simultaneously. 

Fig. 7 dq>icts a flow chart 210 diat may be used to establish a link active 
schedule in the Fieldbus network. A block 21 1 within the cotttioller 12 receives the 
LAS schedule installation scrq>t as developed by the configuration tool for the 
Fieldbus ccHnmunicaticm networic after accountii^ for aU of the 
communications that must take place over die Fieldbus bus, including those 
necessary for the shadow function blocks. Of course* diis installation script can be 
produced usipg known tools available for the Fieldbus communicaticm protocol 
which may also be integrated into the controller 12 configuration tool. A block 212 
then installs the LAS schedule to the targeted Fieldbus port, which may be, for 
example, the interface card 40 of Fig. 5. 

Thereafter, a block 213 auUHnatically creates subscriber links and VCRs 
within the fieldbus netwoik based on the data published by the Fieldbus devices. In 
particular, these subscriber links are created so that the interface card 40 subscribes 
to the lixiked parameters of the Fieldbus function blocks for vAdth shadow function 
Modes exist within the controller 12. Likewise, the interface card 40 publishes data 
that is generated by function blocks within the condrolte 12 and that is sent to the 
shadow function blocks widiin the controller 12 as a linked parameter. Generally 
speakmg, the interface card 40 acts as a function block proxy for the linked data to 
and from the shadow function blocks. Ftohennore, the interface card 40 acts as a 
function block proxy to request view object and alert object information from the 
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actual function blocks for which shadow function blocks exit so as to update the 
non-linked data associated with the shadow function blocks within the controUer 12. 

A block 214 dien maps the LAS installation status into the controller (or 
Delta-V) status so that the controller 12 may determine if the LAS installation has 
been accepted or rejected by die Fieldbus network. This enables the controller 12 
to verify whettier the instaUation of the Fieldbus iiecwork has occurr^ 

Fig. 8 depicts a flow chart 220 indicating die steps used to set iq> publisher 
links within the Fieldbus network. A block 221 in the controller 12 receives the 
publisher links created by the workstation configuration tool for the Fieldbus 
network and a block 222 then sends these publisher links to the interface card 40 to 
establish the publisher links and die associated VCRs required to support the 
shadow function block communicaticms as well as other communications on the 
Fieldbus bus 42. 

Fig. 9 depicts a flow chart 230 ilhistrating the steps associated with 
installing a device configuration within a Fieldbus device. A block 231 receives die 
device configuration installation scr^t from the workstation as configured by die 
configuration tool after all of the links and other information for that device have 
been established. A bloc* 232 then clears the previous configuration in the device 
by sending appropriate commands to the device via the interface card 40. While not 
stricdy necessary, it has been found diat it is desirable to clear the previous device 
configuration before trying to install a new device configuration in the Fieldbus 
device to thereby prevent installation problems. 

A block 233 then installs the VCRs and a block 234 installs the links 
i»:essary to implement communication according to die link active schedule and 
publishCT/subscriber relationships established for the Fieldbus network. A block 
235 then installs the Fieldbus start list to the device, which synchronizes die 
function block execution of that device with the execution of other function blocks 
in other devices of the Fieldbus network. Thereafter, a block 236 installs the 
macrocycle to the device after that macrocycle has been ctmqmted or determined to 
account for all of the synchronous communications necessary to occur over the bus 
42 associated with the Fieldbus. 
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Fig. 10 dq)icts a flow chart 240 iUustratiiig the steps used to set iq> a 
particular function block within a particular device within the Fieldbus network. A 
block 241 first receives a function block installation script as developed by the 
configuration tool. A block 242 then installs the next fui»:tion block and execution 
poiod parameters* as is typically done when configuring a Fieldbus function block. 
Thereafter, a blodc 243 sets die function blodc mode to out of service, which is 
iiecessary to change values widiin the function blodc. A block 244 then installs the 
fimcdon block parameter configured values or user overrides (i.e., the user defined 
values) within the funcdon blodc These user configured values may be established 
in any manner, such as through the use of dialog boxes in tbe workstation during 
the configuration of the process control system. Thereafter, a block 24S sets the 
function block mode to the configured value so that the function block will operate 
according to the manner in which it is configured. 

It will be understood that the flow charts of Rgs. 7-10 are merely indicative 
of die normal steps that are used to configure a Fieldbus network. In this case, 
however, the set up of the Fieldbus networic accxmnts for aod includes die 
publisher/subscriber links and VCRs required tt> support die operation of any 
shadow funcdon blocks within the controller 12. Of course, the user woricstation or 
controller 12 may configure the Fieldbus network automatically based on the 
infomiation provided by the user about the set up of the control system during die 
configuration of that system. 

Refemng now to Fig. 11, a flow chart 250 illustrates the operation of a 
shadow function block when a control module includiqg that shadow function block 
is run on the controller 12 to perform process control. As will be unders»x>d, the 
controUo- 12 inq>lements the blocks within a particular module (such as the blocks 
102, 104, 106 and 108 of Fig. 4) at the module scan rate associated with the 
module. However, communication of linked data (such as that defined by the links 
in the diagram of Fig. 4) between actual FieMbus function blocks and the shadow 
function blocks occurs at the synchronous macrocycle rate of the Fieldbus network, 
which may be different than the module scan rate of the controller 12. As a result, 
the data for the linked parameters is typically stored in the lower database 156 of 
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tbe controller 12 at a diffeient (usually faster) rate than the data for non-linked 
parameters. 

When the shadow function block is inq)lemented in the controU^ 12, a 
block 252 scans the operattonal data stored withm the lower database 156 of the 
contioller 12. That is. during each module p»iod, the operational data that has 
been stored in the lower database 156 by the interlace module 40 is read. Ablock 
254 determines if the scan succeeded. If not. a block 256 updates the block error in 
the shadow function block, sets the shadow function block output status to bad and 
sets the port integrity to indkate to the controUer 12 that the shadow function block 
has felled and that, theiefoie. there may be a problem with respect to the external 
function block or with respect to commumcations with the external fimction bkwk 
within the Fieldbus network. If sudi an error is detected, flie shadow function 
bkjck data is not updated (as that data is old or bad data in any event) and the 
operation of updating the data within die shadow function block stops for that 
module scan cycle. However, if the scan succeeds, a block 258 copies the received 
operational data into the shadow function block. Of course, the operational data 
includes not only the data obtained by the view and alert objects at the module scan 
rate but also the data for the linked parameters which is obtained and placed into the 
lower database 156 at the rate determined by the macrocyde of the Fieldbus 
iKtwork. 

A btock 260 then determines whether the static revision parameter associated 
wifl» the actual fimction block (which is provided by ^ view object operation) has 
increased. If so, a block 262 instructs the interface card 40 to read the static data 
associated widi the Fieldbus function block and to forward Oiat static data to the 
lower database 156, where this data is read and placed into the shadow function 
block. As is known, the static revision indicates whether any of the static data 
normaUy provided by the static view list is changed. If the static revision is not 
increased, none of the static data is changed and it is not necessary to read that data 
during each cycle of the control module. However, if the static data revision is 
hicreased, then some of the static data has changed and that static data needs to be 
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read and placed in the shadow function block so as to make the shadow function 
block nuTTor the data that is actually within the external function block. 

After the static data is obtained, or if the static revision has not increased, a 
block 264 maps the Fieldbus alarms (ami other data if necessary) into the alarms (or 
5 other data fields) of the controller 12. This mappiqg may be accomplished using a 
lookup table or by any otba taapping technique. The m^>ped alarms (and other 
data) are then stored in tiie shadow function blodc to be used by odier control 
blocks of the comrol module. The abrms may also be displayed to a user or used 
in any odier desired manner. 

10 Thereafter, a block 266 determines whether die data for the liidced 

parameters is stale (i.e., is out of date). Such an indication is regularly provided in 
Fieldbus commimications and indicates that the data being received was not 
generated in the most recent macrocycle of the Fieldbus network, v/tdch may 
indicate that a timing or other problem exists within the Fieldbus network. If the 

IS Unk parameter data is stale, a block 268 marks the output data as BadNotConnected, 
which may change die mode or status of other functicm blocks within the controller 
12. Thereafter, or if die linted data is not stale, a block 270 makes tibe operational 
data visible to other blocks within die controller 12 and the controller 12 continues 
to operate based on the new operational data. 

20 As will be understood, the flow chart of Fig. 11 illustrates die operation of 

updating the shadow function block to assure that it mirrors the data associated with 
the external fuiK:tion block within an external device. However, the shadow 
function block may also communicate data and send write commands to the external 
funcdon block. Such data and write commands may be provided from a user at, for 

25 exan^le, a woricstation or may originate and be sent by odier funcdon blocks within 
the controller 12 via established links. Referring now to Fig. 12, a flow chart 280 
illustrates the steps taken to send data or write commands to an external funcdon 
block via the shadow funcdon block. At a block 281, a control block within the 
controller 12 writes data via an vapuxt link to the shadow funcdon block. 

30 Alternatively, a user may send a write command to the shadow funcdon block via a 
user interface which may allow a user to, fen* exanqile, manually change a set point 
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or other value associated with the external function block. The shadow function 
block then immediately sends a write command or other data to the interface card 
40. If such data or command is associated with a linked parameter, die interface 
card 40 publishes die data on die Fiel<n>us bus to die external function block at the 
s^n^riate or ^nchronous time as defined by the macrocycle of die Fieldbus 
networic. Ifdie write command or data is not associated with a linked parameter* 
die inter&ce card 40 uses asynchronous comnwinicatioiis to relay die command or 
data to die external fiinction block. Thereafter, the ^Eternal fimction block receives 
the data or command and updates its attribute parameters accordingly. These 
changes are then communicated back dirough the interface card 40 using 
publishn^/subscriber communications as well as the view object operation and the 
new data is placed in the lower database 156 where, during the next scan cycle of 
die control module, that data is placed into die shadow fiinction block. 

When die block 282 sends a write request to the interifiaice card 40 and diat 

request is sent to the external fiinction block, the interface card 40 receives a 
response ftom the function block indicating whether die write has been completed 
or \(*ether the data has been accepted or received. The interface card 40, in turn, 
sends this response to the shadow function block. If the write failed, the status, 
alarm or error settings of die shadow function block may be changed to reflect that 
enor. Thus, for «caiiq>Ie, if a write request associated with a tinted parameter was 
not received or was not properly implemented by die imerface 40, diis may be 
iiyfiraf«>ri in die oxor status of die shadow fimction blocic If desired, vfbea a writt 
command which originated with a user fails to be inqilementBd. a block 283 may 
send an indication of such failure to die user at a workstation or odier user interface 
to thereby notify die user of die failed attempt to write to the external function 
block. 

While the description hereof has been directed to the inqilementation and use 
of a single shadow fimction block 108, it wiU be understood diat multiple shadow 
fiinction blocks can be inqilemented in the same control module or controller to 
enable the comrol module or controller to use multiple exiMnal function blocks. 
Furthermore, shadow function blodcs can be implemented using any exuxoal 
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process control communication protocol (besides the Fieldbus protocol) and may be 
used to communicate with any type of function block im:ludiiig any function block 
that is similar to or the same as any of the different function blocks specifically 
identified by and supported by the Fieldbus protocol. Moreover, while shadow 
function blocks are described herein as being associated with an exterml function 
block in the form of what the Fieldbus protocol defines as a "function block," it is 
noted that the use of the expression 'function block" herein is not limited to what 
the Fieldbus protocol identifies as a function block but, instead, includes any other 
type of block, program, hardware, firmware, etc., associated with any type of 
control system and/or communication protocol and that can be used to implement 
some control function. Thus, while function blocks typically take the form of 
objects within an object oriented programming environment, this need not be case 
and can, instead, be other logical units used to perform particular control (includiiig 
input and ou^ut) functions widiin a process control environment. 

Moreover, although the shadow function blodc described herein is preferably 
implemented in software stored in, fx example, a controller or other process 
control device, it may alternatively or additionally be implemented in hardware, 
firmware, etc., as desired. If inq>lemented in software, tibe shadow function block 
of the present invention may be stored in any conq>uter readable memory such as on 
a magnetic disk, a laser disk, or otter storage n^um, in a RAM or ROM of a 
computer, etc. Likewise, this software may be delivered to a user or a device via 
any known or desired delivery mediod inchidii^, for example, over a 
communication channel such as a telqxhone line, the internet, etc. 

Also, wtulc the shadow functim block of the present invention is described 
in detail in conjunction with a process control network that implements process 
control functions in a decentralized or distributed manner usipg a set of Fieldbus 
devices, it should be noted diat the shadow function block of the present invention 
can be used with process control networks that perform control functions using 
other types of field devices and connnunication protocols, including protocols that 
rely on other than two-wire buses and protocols that support analog and/or digital 
communications. For example, the shadow function block of the present invention 
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can be used in any process control network that uses devices confonning to the 
HART. PROFIBUS, etc. communication protocols or any other communication 
protocol that i»w exists or that may be developed in the fiinue. Likewise, if 
desind. the shadow function block of Ae present invention can be used in process 

5 control networics that do not have distributed control functions but, instead, that use 
a centralized controller or control scheme to control the devices dierein. 

While the present invention has been described wifli referrace to specific 
exanq)les. which are intended to be illustrative only and not to be limiting of the 
invention, it will be appsaeat to those of ordinary skill in the art that changes, 

10 additions or deletions may be made to the disclosed embodiments without departing 
from Ae spirit and scope of tfie invention. 
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CLAIMS 



1. An interface function block for use in a process controller that is 
communicatively coupled to an external device via a communication network, 
i^rein the proc«s controller inqilemrats a control routine using an internal 
function block disposed within die process controller and an external function block 
disposed within the external device* the interfiioe fiu^on block con^yrising: 

a communication port haviqg an input that communicates with the 
external function blodc via die conmninication n^work to receive data 
pertaining to the external function block, and 

a memory that stores die received data pertaining to the external 
function block accordiqg to a configuration protocol of the internal function 
block. 

2. The interface function block of claim 1, furdier inciiuling an output 
that provides the data pertainiqg to die external function block to die internal 
fuKtion block according to the conQguration protocol of the int»nal function 
block. 

3. The interface function block of claim 2, wherein the input of the 
communication port receives the data pertainiiig to the external function block 
independently of the operation of the internal function block. 

4. J The interface function block of claim 2, wherein the external function 
block communicates via the communication networic using a first communication 
protocol that is different dian a seccmd communication protocol associated with the 
configuration protocol of the internal fiinction block and wherein the input of the 
communication port communicates widi the external function block using the first 
communication protocol and the output communicates with the internal function 
block according to the second communication protocol. 
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5. The interfece function block of claim 4, wherein the first 
communication protocol is a Fieldbus communication protocol and wherein the 
input of the communication pott communicaies with the external function block 
using the Fieldbus commnniration protocol. 

6. The interfece function blodc of daim 5. wherein the input of the 
communication port uses an imerfece device configured to communicate with the 
external device using the Fieldbus communication protocol to communicate with the 
external function block. 

7. The interfece function block of claim 1, wherein the communication 
port coinraunicates with the external fimction block using synchrony 

oomaiuiucatioQS . 

8. Theinterfaccfimcdonblodcofclaiml.whereinihecomfflunication 
port conmiunicates with the external function blodc using synchronous and 
asyncfannKHis communications. 

9. The mierface function block of claim 1 , wherein the external device 
^.^i«ir«r«^ using a device communication protocol that supports the 
communication of logically linked packets of data using standardized 
communication calls, and wheiem the communication port communicaies with the 
external function block using the standardized communication calls associated with 
the device communication protocol. 

10. The interface function block of claim 9. whercm the device 
communication protocol is a Fieldbus communication protocol, and wherein the 
communication port communicates with the external device usmg view objects 
within the Fieldbus communication fsotocol. 
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1 1 . The interface function block of claim 1 , wherein the communication 
port receives an alarm indication from the external function block and wherein the 
memoiy stores the received alarm indication. 

12. The interface function block of claim 1, wterein the comraunication 
port furdier includes an output diat sends data to die external function block using a 
communication protocol associated wiib die external function block. 

13. A coimt)ller adapted to be communicatively coupled to a plurality of 
field devices wherein one of die field devices includes an external function block 
that communicates using a device communication protocol, the controller 
camprwBg: 

a processor; 
a memory; and 

a control routine stored in the memoiy and implemented by the processor to 
control the plurality of field devices* the control routine including; 

a multiplici^ of interconnected internal function blocks configured 
using a controller protocol and implemented by the controller; and 

an interface function block that communicates with one of the 
multiplicity of interconnected internal function blodcs usii^ the controller 
protocol and that communicates wi^ the external function block within the 
one of die field devices usii^ die device communication protocol* wherein 
the interface function block stores data pertaining to tte external function 
block received fmn die external function Mode. 

14. The controller of claim 13, wterein the interface function block 
receives the data pertaining to the external function block indqiendendy of the 
operation of the multiplicity of internal function blocks. 
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15. The controller of claim 13, wherein the device communication 
protocol is a Fieldbus commwiication protocol and wherein the interface function 
block communicates with the external function block using the Fieldbus 
communication protocol. 

16. The controller of claim IS, wherein the interface function block 
communicates with the external function block usii^g view objects within the 
Fieldbus communication protocol. 

17. The controller of claim 15, wherein the interface function block 
communicates with the ex^mal function block using subscriber/publisher 
communications within the Fieldbus commamication protocol. 

18. The controller of claim 13, wherein the interfiaice function block 
receives and stores data pertaining to inputs and outputs of the external function 
block. 

19. The controller of claim 13, wherein the interface function block 
receives and stores data pertaining to alarms generated by the external function 
block. 

20. The controller of claim 13, wherein Oie inter&ce function blodc 
receives and stores data pertaining to the mode of the external function block. 

21 . The controller of claim 13, wherein the inter&ce function block 
sends data generated by the one of the multiplicity the internal fiim:tion blocks to 
the external function blodc. 

22. The controller of claim 13, wherein the inierfoce function block 
sends a conmaarid generated by the controller to the external function block. 
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23. A method of iiiq>leiiieiidx^ a control routine within a process 
controller conuminicatively coupled to a field device', wherein the field device has 
an external function block located therein and conununicates using a device 
conununication protocol, the method conq>rising the steps of: 

S storing a plurality of interconnected internal function blocks in tte controller 

configured accwding to a controller protocol for inq>lementation as part of the 
control routine; 

creating an interface function block within the controller configured 
according to the controller protocol, wherein the interface function block 
10 communicates with Ae external function block using the device communication 
protocol; 

creating a control routine that uses the plurality of interconnected internal 
function blocks and the^ interface function blodc to control the process; and 

storing data associated with and received from die external function block in 
IS tte interface function block duriqg implementation of tbt control routine. 

24. The method of claim 23, furdierincludii^ the stq> of using the 
interface function block u> conmnmicate ^xith die external function block to update 
the data associated with the external function block indq»endmtly of the c^ration 
of the internal function blocks. 

20 25. The method of claim 23, further including the st^ of using the 

interface function block to commimicatc fuidier data to the external fuiK:tion block 
to alter the configuration of die external function block. 
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26. The method of claim 23, further including the steps of allowing a 
user to configure the control routine by specifying each of a number of function 
blocks to be used in the contiol mutiiie, iitentifying the interconnectioiis between 
the specified function blo(ds to be used in tiie control routine and specifying the 
location of a particular specified functi(Hi block as being an internal fiuiction block 
inq)lemented in the controller ot fl»e external fimction block inqilemented by the 
field device. 

27. The method of claim 26, wherein the step of specifying the location 
of the particular specified function block as being the external function block 
includes the step of sdecting an external device in which the extendi fiiiK:tion blodc 
is to be inq>leniented from a list of external devices connected to ibR controller. 

28. The mediod of cJaim 23, ixdiereintiiestqp of storing the data 
associated widi the extornal ftmction block incudes the step of storing an alarm 
indication generated by the external function block in the interface function block 
and wherein the method furtiier includes the step of using the alarm indication 
stored in tte interface function block to trigger alarm processing within the 
controller. 

29. The medxxi of daim 23, fiirdwr includhig the step of displaying flie 
control routine 1^ diq>layii« dq»k:tion of the internal function blocks, a dq>iction 
of the interface function blodc and depictions of tiie intercoimections between the 
internal function blodss and the intnface fimction blocks so that the interface 
functi(m block represents the external fiuiction blodc 
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